Bug

commons/tenant-manager/redis/client.go (v5.3.1) builds a tls.Config with no RootCAs when cfg.TLS=true, so Go falls back to the system trust pool. On macOS the system trust path uses Apple's Security Framework, which rejects valid Amazon-issued ElastiCache/Valkey certs as "certificate is not standards compliant" — a strictness mismatch with Go's pure-Go verifier when the same chain is supplied via an explicit RootCAs pool.

Empirical evidence (Valkey 7.2.4 / ElastiCache, TLS-required, default-user auth)

Cluster sample: master.tenant-manager-devops-valkey.1tj5cc.sae1.cache.amazonaws.com:6379

Change

Adds an OPTIONAL CACertBase64 field to TenantPubSubRedisConfig. When set and TLS is enabled, the decoded PEM bundle populates tls.Config.RootCAs. Mirrors the pattern already used by commons/redis (TLSConfig.CACertBase64) and the tenant-manager Mongo client.

type TenantPubSubRedisConfig struct {
    Host         string
    Port         string
    Password     string
    TLS          bool
    CACertBase64 string  // NEW — OPTIONAL
}

Backward compatibility (hard guarantee)

The field is additive and optional. No existing caller breaks.

A regression test explicitly asserts the empty-CA + TLS-on path keeps RootCAs nil, so future refactors can't silently break system-trust callers.

Test matrix

All in commons/tenant-manager/redis/client_cacert_test.go, build tag //go:build unit, deterministic (self-signed ECDSA P-256 CA generated in-test — no public CA bundle embedded):

• TestBuildOptions_CACertBase64_EmptyWithTLS_PreservesSystemTrust — regression guard for the backward-compat invariant.
• TestBuildOptions_CACertBase64_ValidPEM_PopulatesRootCAs — happy path, RootCAs.Equal() against the supplied cert.
• TestBuildOptions_CACertBase64_InvalidBase64_ReturnsWrappedError — fail-fast decode error.
• TestBuildOptions_CACertBase64_ValidBase64_NotPEM_ReturnsError — fail-fast PEM error.
• TestBuildOptions_CACertBase64_IgnoredWhenTLSDisabled — TLS off is honored.
• TestBuildOptions_CACertBase64_TableDriven — full 6-case matrix.

The 4 pre-existing tests in client_test.go and coverage_boost_test.go pass unchanged.

Verification

go build ./...                                                   — clean
go vet ./...                                                     — clean
golangci-lint run ./...                                          — no issues
go test -tags=unit -count=1 ./commons/tenant-manager/redis/...   — 22/22 pass
go test -tags=unit -count=1 ./...                                — 4549/4549 pass across 49 packages

Downstream impact

plugin-br-bank-transfer (and any other consumer with the same macOS-vs-AWS-CA pain) will:

1. Bump lib-commons to the new patch tag once released from main.
2. Read a new MULTI_TENANT_REDIS_CA_CERT env var (base64-encoded Amazon Root CA 1 PEM).
3. Pass that value to CACertBase64 when building TenantPubSubRedisConfig.

The new field's GoDoc explicitly names MULTI_TENANT_REDIS_CA_CERT as the canonical downstream env to keep wiring consistent.

Hotfix logistics

• Target branch: main (hotfix), patch bump expected via semantic-release on fix: commit type → next tag should be v5.3.2.
• CHANGELOG.md: intentionally not edited in this PR — semantic-release regenerates it post-merge per .releaserc.yml.
• Back-merge to develop: required as a follow-up so the field reaches the next minor pre-release. The repo's standard develop-backmerge workflow (chore(changelog): backmerge main into develop) should handle it; if not, a follow-up PR main → develop is needed. Not part of this PR.

Constraints respected

• Default behavior unchanged.
• No panics; %w error wrapping; ctx-first preserved on the NewTenantPubSubRedisClient signature.
• Field-style config (consistent with the existing TenantPubSubRedisConfig shape).
• Commit signed (-S) with trailer X-Lerian-Ref: 0x1.